<html>
<head><meta charset="utf-8"><title>Optimizations that improve compile time but regress runtime · t-compiler/wg-mir-opt · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/index.html">t-compiler/wg-mir-opt</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html">Optimizations that improve compile time but regress runtime</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="212834312"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/212834312" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jonas Schievink  [he/him] <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#212834312">(Oct 09 2020 at 14:39)</a>:</h4>
<p>So in <a href="https://github.com/rust-lang/rust/issues/77680">#77680</a> I tried turning on <code>UnreachablePropagation</code> by default, and as it turns out the LLVM regression is gone. Unfortunately the way the optimization works kind of fundamentally removes information that LLVM would be able to exploit (to determine possible integer ranges/values, etc.), so it regresses runtime performance.</p>
<p>I wonder what the right way to handle this would be. Maybe mir-opt-level=2 should be the default when opt-level&gt;=2, then we could run this optimization only at mir-opt-level=1 without regressing runtime perf?</p>



<a name="212834689"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/212834689" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Wesley Wiser <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#212834689">(Oct 09 2020 at 14:42)</a>:</h4>
<blockquote>
<p>Maybe mir-opt-level=2 should be the default when opt-level&gt;=2, then we could run this optimization only at mir-opt-level=1 without regressing runtime perf?</p>
</blockquote>
<p>Yes, I would really like for it to work that way. Inlining (or at least, the more aggressive version of it) is probably another MIR optimization that would be good to enable if the user is requesting optimizations and should be disabled otherwise.</p>



<a name="212854208"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/212854208" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#212854208">(Oct 09 2020 at 17:29)</a>:</h4>
<p>MIR-level inlining might still be useful at low opt levels for generic functions calling tiny generic functions, since it can probably reduce the amount of code materially.</p>



<a name="212854630"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/212854630" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#212854630">(Oct 09 2020 at 17:33)</a>:</h4>
<p>Things like <code>Option::as_ref</code> just disappearing seems like good at all levels.</p>



<a name="212855090"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/212855090" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Wesley Wiser <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#212855090">(Oct 09 2020 at 17:37)</a>:</h4>
<p>For sure! I think we will definitely want to tweak the inlining strategy for different opt-levels though. For debug builds, incremental performance matters a lot and inlining can create additional scenarios where we'd need to recompile functions besides the ones you just changed (because maybe the function you changed was inlined into a bunch of other functions). </p>
<blockquote>
<p>generic functions calling tiny generic functions, since it can probably reduce the amount of code materially.</p>
</blockquote>
<p>That's definitely true. We may even want to consider just skipping the inliner entirely if the function we're processing isn't generic (for debug builds).</p>



<a name="222476939"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/222476939" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> tm <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#222476939">(Jan 12 2021 at 18:49)</a>:</h4>
<p>There are also a few simple transformation one could start doing at opt-level=0 and debuginfo=0. At opt-level=0, we could remove the storage markers since they won't be used by LLVM nor by CTFE, which "soon" will have its own MIR. Similarly at debuginfo=0, the locals that are used only by debuginfo could be removed.</p>



<a name="223145974"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/223145974" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#223145974">(Jan 18 2021 at 17:18)</a>:</h4>
<p><span class="user-mention" data-user-id="352985">@tm</span> "its own MIR"? Interesting. Can you say more about that?</p>



<a name="223146306"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/223146306" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Wesley Wiser <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#223146306">(Jan 18 2021 at 17:21)</a>:</h4>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> That landed in <a href="https://github.com/rust-lang/rust/pull/78407">https://github.com/rust-lang/rust/pull/78407</a>. CTFE now uses unoptimized MIR so that it can detect UB that might not have been preserved by optimizations.</p>



<a name="223146427"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/223146427" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#223146427">(Jan 18 2021 at 17:22)</a>:</h4>
<p>Ah, so the same MIR, just at a different phase? That makes more sense.</p>



<a name="223146491"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations%20that%20improve%20compile%20time%20but%20regress%20runtime/near/223146491" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Wesley Wiser <a href="https://rust-lang.github.io/zulip_archive/stream/189540-t-compiler/wg-mir-opt/topic/Optimizations.20that.20improve.20compile.20time.20but.20regress.20runtime.html#223146491">(Jan 18 2021 at 17:23)</a>:</h4>
<p>It's the same MIR in the sense that it's identical to the MIR before optimization occurs but it is <code>clone()</code>'d I believe.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>